home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16185 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: Tue, 09 Apr 96 16:15:25 GMT
  6. Organization: none
  7. Message-ID: <829066525snz@genesis.demon.co.uk>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> <dewar.829051685@schonberg>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <dewar.829051685@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes:
  15.  
  16. >  Sorry, this is wrong, I lied to the *implemention* of the function as
  17. >  it occurred in Linux. Now it is true that the spec of the function is
  18. >  different in Linux than in other systems (you quoted the manual pages
  19. >  that showed this clearly). So of course we have a portability problem
  20. >  here. Read is different in different systems, not only at the
  21. >  implementation level, but at the spec level. The program in question
  22. >  was correct with respect to the spec on "other systems":
  23.  
  24. What makes the code non-portable is that it depends on a behaviour of read()
  25. that is not guaranteed by the relevant standard (POSIX in this case). That
  26. this may be down to vagueness in the standard doesn't change the fact. In
  27. some cases there may be an argument based on clear intent but I don't think
  28. this is one of them. Linux just happened to be the first system that showed
  29. up the inherent non-portability of the code.
  30.  
  31. Correctness considerations aside, there is never a good reason to pass
  32. a value in the 3rd argument to read() that is greater than the available
  33. buffer size. IMHO code that does this is highly suspect whether or not
  34. you argue that it is legal. I wish more systems were like Linux and trapped
  35. this, maybe they will in the future.
  36.  
  37. >>I checked the manual pages for read() on several systems. Linux documents
  38. >>that results if the buffer pointed at by buf is outside of the address space
  39. >>of the process. On other systems, it is claimed that EFAULT results if
  40. >>the buf pointer is directed outside of the address space.
  41. >
  42. >  Kazimir, perhaps you don't understand the whole idea of specs, but that
  43. >  quote means that code that makes sure that the pointer is directed inside
  44. >  the address space is OK if the buffer is not overrun!
  45.  
  46. Right, it appears that the spec. for 'other systems' is incorrect (or at
  47. least unlikely to match what happens in practice).
  48.  
  49. -- 
  50. -----------------------------------------
  51. Lawrence Kirby | fred@genesis.demon.co.uk
  52. Wilts, England | 70734.126@compuserve.com
  53. -----------------------------------------
  54.